Professional Soft Collection 1.02/Professional Soft Collection 1.02.iso/qemm.80c/technote.qip/XSTI.TEC

Text File | 1995-11-04 | 17KB | 366 lines

                    QEMM and the XSTI Parameter

 Quarterdeck Technical Note #233              Filename: XSTI.TEC
 by Quarterdeck Testing and Compatibility   CompuServe: XSTI.TEC
 Last revised: 05/01/95                       Category: QEMM

 Subject: Detailed information on the use of QEMM's XSTI parameter,
           which can be used when QEMM reports "Disabling Stealth
           ROM because QEMM could not locate the ROM handler for INT
           XX."

 Q. Why do I see this message when I start my computer?

     QEMM386: Disabling Stealth because QEMM could not locate the
              ROM handler for INT XX"

 A. There are three possible causes:

     1) You are loading a driver before QEMM which is grabbing
        interrupt XX; OR

     2) A ROM is loading a handler for interrupt XX into RAM.

     3) You are using a computer which was upgraded to an 80386 with
        an add-in board, such as the Intel "Inboard PC."

     There are several potential solutions:

     1) Load the driver in question after QEMM.  If it must be
        loaded before QEMM, load HOOKROM.SYS before you load this
        driver.

        During installation of QEMM, HOOKROM.SYS is installed in the
        QEMM directory. Assuming that QEMM is installed in a
        directory called QEMM on your "C" drive, the new line would
        look like this:

        DEVICE=C:\QEMM\HOOKROM.SYS

        HOOKROM is a device driver that may be needed if you use the
        Stealth ROM feature and are loading one of your device
        drivers before QEMM386.SYS in the CONFIG.SYS file.  Though
        it is usually best to load device drivers after QEMM386.SYS,
        there are some special drivers (like the ones that manage
        some 80386 conversion hardware) that must load before
        QEMM386.SYS.  These drivers can obscure information that
        QEMM needs to enable the Stealth ROM feature, in which case
        QEMM386.SYS will post the above error message.

        Placed before QEMM386.SYS in the CONFIG.SYS, HOOKROM will
        gather the necessary information for QEMM386.SYS and prevent
        this special driver from interfering with the Stealth ROM
        process.

     2) Add the parameter "XSTI=XX" (where "XX" is the number of the
        interrupt reported in the message) to the QEMM386.SYS line
        of the CONFIG.SYS, then add the appropriate eXclude to this
        same line in order to keep QEMM from mapping over the
        portion of the address space where the ROM handler for
        interrupt XX resides.  (See "HOW DO I FIND THE APPROPRIATE
        EXCLUDE?" below.)

        It may also be possible to reconfigure your system in such a
        way that the ROM no longer redirects an interrupt into RAM.
        This is the case with the Invisible Network.  (See "KNOWN
        USES FOR XSTI" near the end of this technical bulletin.)  It
        is also possible that a program you are trying to run, or
        even your operating system, wants to have a particular
        interrupt remain unStealthed. XSTI, with the appropriate
        eXclude, is necessary to get your program, or operating
        system, working with Stealth ROM.

     3) Add the following parameters to the QEMM device line in your
        CONFIG.SYS file:

        XSTI=70 XSTI=74 XSTI=75 XSTI=76

        A typical QEMM line would look like this:

        DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=70 XSTI=74 XSTI=75
         ... XSTI=76

        (Note that the preceding two lines should be on a single
        line in CONFIG.SYS.)

 Q. How do I find the "appropriate exclude"?

 A. First, note that QEMM's Stealth Testing will find automatically
     the majority of circumstances that will require XSTI, and will
     make the appropriate exclusions or S-pages.  If the conflict
     you experience does not happen as part of the boot process.
     You find the appropriate eXclude by excluding all the address
     space occupied by ROMs, using the parameter FSTC, and doing an
     Analysis.  First, locate all your ROMs.  You can do this by
     looking at the First Meg/Overview screen of Manifest.  Those
     with non-Micro Channel machines and VGA video typically have a
     system ROM at F000-FFFF and a video ROM at C000-C7FF.  Those
     with PS/2s or other Micro Channel machines typically have one
     ROM at E000-FFFF.  Add-on devices, such as some disk controller
     cards and network cards, may also have ROMs, which you must
     eXclude as well.

     A typical QEMM line for a non-Micro Channel machine is:

     DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=F000-FFFF
     ... X=C000-C7FF FSTC

     (again, all on one line).

     On a PS/2 or most Micro Channel machines, the line will look
     like this:

     DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=E000-FFFF FSTC

     In the above examples, XX is replaced with the interrupt
     reported in the QEMM error message.

     Reboot your computer with this CONFIG.SYS.  Stealth ROM
     should work this time. Use your computer for a while, then
     look at the QEMM/Analysis screen of Manifest.  You will see a
     chart that looks something like this:

                      n=0123 4567 89AB CDEF
                   0n00 OOOO OOOO OOOO OOOO
                   1n00 OOOO OOOO OOOO OOOO
                   2n00 OOOO OOOO OOOO OOOO
                   3n00 OOOO OOOO OOOO OOOO
                   4n00 OOOO OOOO OOOO OOOO
                   5n00 OOOO OOOO OOOO OOOO
                   6n00 OOOO OOOO OOOO OOOO
                   7n00 OOOO OOOO OOOO OOOO
                   8n00 OOOO OOOO OOOO OOOO
                   9n00 OOOO OOOO OOOO OOOO
                   An00 OOOO OOOO OOOO OOOO
                   Bn00 OOOO OOOO OOOO OOOO
                   Cn00 IIII IIII OOOO OOOO
                   Dn00 OOOO OOOO OOOO OOOO
                   En00 OOOO OOOO OOOO OOOO
                   Fn00 IIII IIII OOII IIIO

     Consulting the ANALYSIS section of your Manifest or QEMM
     manual, you will read that an "I" indicates a portion of the
     address space that HAS NOT been accessed and an "O" indicates a
     portion of the address space that HAS been accessed.  You must
     eXclude that portion of the address space in the eXcluded ROMs
     where you now see "O"s.

     In this example (which presumes that the ROMs were located from
     C000-C7FF and F000-FFFF), the appropriate eXclude is
     "X=F800-F9FF", an 8K portion of the address space.  This is the
     portion of the address space where the ROM handler for the
     interrupt XX resides.  Our QEMM line, with appropriate
     excludes, would read as follows:

     DEVICE=C:\QEMM\QEMM386.SYS RAM ST:M XSTI=XX X=F800-F9FF

     PLEASE NOTE:  The FSTC parameter is used only during this
     analysis process and should be removed afterward.  Because the
     last 64 bytes of the First Meg address space (in FFFC-FFFF) is
     still addressed directly with Stealth ROM, the last 4K piece of
     the QEMM/Analysis screen will always have an "O" in it, whether
     an eXclude is appropriate or not.

     ALSO NOTE:  This procedure IS NOT used to find INCLUDES in
     portions of the address space NOT occupied by Stealthed ROMs.
     If you wish to experiment with INCLUDES (in order to gain
     additional High RAM) you must perform a complete analysis as
     described in the ANALYSIS section of the QEMM or Manifest
     manual.


 Q. What if there are no "O"s?

 A. It is possible that there are no "O"s at all:  this is because
     the ROM handler for interrupt XX has been replaced by a new
     interrupt handler and the one in the ROM is not being accessed
     at all.  No eXclude is necessary in this case.


 Q. What are the known uses for XSTI?

 A. There are several known instances of a need for XSTI.  In many
     cases, these parameters will be found automatically by QEMM

     INVISIBLE NETWORK:

     If you use the boot ROM on the Invisible Network cards, it
     loads 32K of code into the top of the conventional memory
     address space, and grabs interrupt 13. A much better solution
     than to use XSTI=13 and the appropriate eXclude is to disable
     the ROM on the network card and load IS2BIOS instead.  This
     will give you 32K more conventional memory (since IS2BIOS can
     be loaded high), and you will not have the network card's ROM
     breaking up your high address space.


     MS-DOS 5 ON SOME ZENITH MACHINES:

     XSTI=18 and the appropriate eXclude is necessary to print on
     some Zenith machines.  This is due to an obscure method used
     only in some Zenith BIOSes. A Zenith version of DOS 5 may not
     have this problem.


     WORDSTAR 2000 version 1.01:

     XSTI=15 and the appropriate eXclude is necessary.  This is due
     to an ancient method of jumping directly to the code that an
     interrupt vector points to. This version of Wordstar 2000 was
     written in 1985. Newer versions may not have this problem.

     VIDEO ACCELERATOR DRIVERS:

     SPEED_UP.SYS is a driver that comes with the Orchid Prodesigner
     video card. It makes a copy of the video ROM in RAM in order to
     speed up your video.  If it is loaded after QEMM on a system
     with Stealth ROM enabled, it refuses to load, complaining that
     someone else has taken Interrupt 10.  If loaded before QEMM on
     the same system, Stealth ROM will be disabled because QEMM
     cannot find the ROM handler for Interrupt 10.

     You can solve both of these problems with XSTI=10. No exclusion
     is necessary because the video ROM is no longer being used.
     Speed_up.sys can then be loaded after QEMM and (and can be
     loaded into upper memory).  However, we strongly recommend that
     you NOT load SPEED_UP.SYS, RAMBIOS.SYS, FASTBIOS.SYS, or any
     similar driver.  Using SPEED-UP.SYS costs you 36K of memory.
     Instead use QEMM's ROM parameter, producing the SAME effect but
     using NO address space between 0-1024K.


 Technical Background
 ====================

 All you need to know to use the XSTI parameter is contained above.
 If you REALLY want to understand what you are doing, keep reading.
 Otherwise, go sit out on the back porch and watch the sun set.

 Q. What does Stealth ROM do to interrupts?

 A. The Stealth ROM feature of QEMM allows you to map High RAM over
     ROMs by intercepting the interrupts that point into those ROMs
     and restoring the ROM into the Page Frame when the interrupt
     comes in, allowing the ROM's code to be run from the Page
     Frame.  QEMM must divert all interrupts that point into a ROM
     it Stealths.  Otherwise, when an undiverted interrupt comes in,
     control will pass to whatever QEMM has mapped into the High
     RAM in that portion of address space, rather than to the ROM
     that originally resided there.

 Q. In what cases might QEMM not find an interrupt handler?

 A. If a program you have loaded before QEMM or a ROM (all ROMs
     load before the CONFIG.SYS) loads an interrupt handler into
     RAM, then, when QEMM loads, QEMM will find this interrupt's
     handler not pointing into a ROM.  An interrupt handler pointing
     into RAM cannot be Stealthed.  If a device driver diverts this
     interrupt, you can load it after QEMM.  If a ROM diverts this
     interrupt into RAM, you should see if there is a way to
     reconfigure the ROM so that it does not.  On the INVISIBLE
     NETWORK, for instance, it is possible to reconfigure the
     network card (by means of a jumper) so that the ROM is no
     longer active and network services are provided by a program.
     In other cases, there may be a configuration program that
     performs this service.

     If you cannot reconfigure the ROM to stop diverting this
     interrupt, then QEMM must be told not to try to Stealth this
     interrupt.  This is what XSTI=XX does. Since the new interrupt
     handler may eventually call the ROM's interrupt handler, the
     ROM's interrupt handler for this interrupt may have to be left
     in place. This is done by eXcluding the portion of the address
     space where the ROM's handler for this interrupt resides.  When
     you eXclude a portion of the address space of a ROM that QEMM
     Stealths, the underlying code that was formerly there returns.

     You can get an idea where this interrupt is by looking at the
     First Meg/ Interrupts screen of Manifest, as it reports the
     beginning address of this interrupt.  The acid test is to do an
     ANALYSIS with all the ROMs eXcluded, which will report what
     portion of the ROM's address space is being addressed directly.
     Typically, only an 8K eXclude is needed.  If the handler for
     the target interrupt is being replaced entirely by the new
     interrupt handler, then the ROM's interrupt handler is never
     called.  In this case, no eXclude is necessary.  To be sure of
     this, you should still run an Analysis.  (See the ANALYSIS
     section of your Manifest or QEMM manual.)

 Q. What if some other program complains about Stealth ROM's
     interrupt diversion?

 A. Some programs, when they load, check to see where the interrupt
     handlers they expect to use point.  If an interrupt handler
     they expect to use is not pointing into a ROM, they think that
     an interrupt they wish to manage is already used by another
     program, and incorrectly assume that there is a conflict.  Such
     programs will see Stealthed interrupts pointing into QEMM's
     code, rather than ROM, and may refuse to run.  If such a
     program cannot be configured to ignore QEMM's diversion of the
     interrupt in question, then this interrupt must be XSTIed and
     the appropriate eXclude found, by the means described above.

     Some programs make a copy of the video ROM in RAM, and divert
     interrupt 10 (the video interrupt) into this new location for
     the video ROM's code.  Such programs (RAMBIOS.SYS,
     FASTBIOS.SYS, RAPIDBIO.SYS are some examples) may refuse to
     load if interrupt 10 has been diverted.  The best solution to
     this problem is to instead use QEMM's ROM= parameter, which
     instructs QEMM to perform this same service without using any
     addresses in the first megabyte of address space. If you wish
     to use such a program anyway, and it has the above complaint,
     then you must use XSTI=10.  No eXclude is necessary, because
     such drivers usurp the video ROM entirely and INT 10 is never
     called again.

 Q. What is FSTC?

 A. The purpose of the FSTC parameter is to make the ANALYSIS
     procedure accurate. When QEMM Stealths a ROM, certain tables
     have to be stored by QEMM in its own data area.  For a video
     ROM, this table occupies 12K; for a disk ROM, this table
     occupies 0.1K (If you have no explicit disk ROM, this table is
     in the system ROM.)   When a ROM is being Stealthed, but the
     address in which the ROM resides is eXcluded, as with
     X=C000-C7FF, then QEMM won't need to make copies of these
     tables in its own data area.  QEMM will automatically save
     memory by NOT making copies of the tables.  This means that
     when you do eXclude the portion(s) of the ROM where these
     tables are stored, the ROM will be accessed directly.  (This
     only holds true when you have used an eXclude.) This will cause
     Analysis to report that a portion of the address space is OK
     (when eXcluded) even though it would not be accessed directly
     were it not eXcluded.

     FSTC (FORCESTEALTHTABLECOPY) forces QEMM to make copies of
     these tables so that inappropriate eXcludes are not recommended
     for the above reason.  FSTC should only be used when you are
     testing a portion of a ROM's address space for direct access by
     eXcluding the whole ROM.  It is not an appropriate parameter
     for a final configuration.


 Summary
 =======

 The XSTI parameter is rarely needed.  If you are loading any
 driver OTHER THAN QEMM 7.0's DOSDATA.SYS before QEMM in your
 CONFIG.SYS file, move QEMM above this driver.  This step alone may
 solve the problem without the use of XSTI.

 If you decide to use XSTI, you MUST determine the appropriate
 eXclude that will return the ROM code for handling the XSTIed
 interrupt to the address space it formerly occupied, because QEMM
 will no longer restore the ROM's code for the interrupt to the
 Page Frame and divert the interrupt there when it comes in.

 ******************************************************************
 *      Trademarks are property of their respective owners.       *
 *   This and other technical notes may be available in updated   *
 *     forms through Quarterdeck's standard support channels.     *
 *          Copyright (C) 1995 Quarterdeck Corporation            *
 ******************** E N D   O F   F I L E ***********************